Display container cell modification in a cell based eui

ABSTRACT

In a cell based EUI, existing display container cells nested within a “host” display container cell are automatically shifted and/or downsized, if necessary, to increase available space to facilitate the creation of another display container cell nested within the “host” display container cell, in response to a request to perform the creation. Similar shifting and/or downsizing are performed to facilitate expansion of one of the nested display container cells; and shifting and upsizing are performed to facilitate contraction of one of the nested display container cells. In one embodiment, shifting and/or downsizing/upsizing are performed in view re-sizing priorities of the display container cells and attributes of a host display container cell governing placement and/or alignment of immediately nested display container cells. In one embodiment, an efficient extended boundary method is employed.

RELATED APPLICATIONS

This application is a continuation of prior Application No. 10/136,679,filed Apr. 30, 2002, priority from the date of which is hereby claimedunder 35 U.S.C. §120.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the field of data processing. Morespecifically, the present invention relates to end user interfaces.

2. Background Information

With advances in integrated circuit, microprocessor, networking andcommunication technologies, an end user of a properly equippedtelevision set or a computing device may receive and consume a varietyof multi-media contents or programming via a number of differentdelivery channels. The end user may e.g. receive and consume televisionprogramming delivered through conventional network broadcast, cable orsatellite. The end user may also receive and consume various multi-mediacontents or programming delivered from various recorded media players,such as VCR tape players, CDROM or DVD players. Alternatively, the enduser may also receive and consume various streaming multi-media contentsor programming delivered through the Internet or other high-speeddigital channel.

The end user interfaces (EUI) employed in these multi-media content orprogramming deliveries are typically limited in their functionalitiesand ease-of-use. In particular, they are typically fixed or inflexible,i.e. non-responsive or lack interactivity with the user. For example, inthe case of television programming, typically only a single view of aprogram (chosen by a director) is provided to the end user (even thoughmultiple views are available from the multitude of cameras employed tocover an event or performance). Even at times, when multiple views of aprogram are provided, the user is unable to change the size, and/orplacements of the different display windows within which the views aredisplayed. Where modifications of the size and/or placement of thedisplay windows are supported (hereinafter, simply windows), typically,automatic relative re-sizing and/or placement of the windows are notsupported. That is, expansion of a window will often result in theblocking of another window (unless the expanding window is a“transparent” window), and contraction of a window will often result inexcess unconsumed space (unless the end user takes overt action toenlarge another window). Similar limitations exist in the delivery ofmulti-media contents or programming from recorded media or streamingthrough the Internet.

Further, the different windows (whether it is of the same program or ofdifferent programs) are usually not easily interchangeable. Inparticular, associated controls, such as “minimize”, “maximize”, or taskbars, are typically not relocatable from one window associated with oneapplication to another window associated with another application. Forexample, in the case of television programming, different views of thesame program delivered through multiple windows are generally notinterchangeable, whereas different programs delivered through differentwindows, such as a primary view and a “picture-in-picture” (PIP) view,are swappable, provided the end user separately changes the channelsassociated with the two windows. In the case of windowed applications,control facilities associated with windows of an application, such as“minimize”, “maximize” or task bars, are typically fixed with thecorresponding windows and/or the application, and may not be moved andbe associated with another window and/or another application.

Thus, an improved end user interface for content or programming deliveryis desired.

BRIEF DESCRIPTION OF DRAWINGS

The present invention will be described by way of exemplary embodiments,but not limitations, illustrated in the accompanying drawings in whichlike references denote similar elements, and in which:

FIG. 1 illustrates an end user view of an EUI implemented in accordancewith the present invention;

FIGS. 2-3 illustrates the anatomy of a cell based hierarchy forimplementing the EUI of FIG. 1, including the universal region cell,region cells, sub-region cells and zone cells, in accordance with oneembodiment;

FIGS. 4-5 illustrate selected aspects of the composition of a“container” cell, including a region cell and a zone cell, in accordancewith one embodiment;

FIG. 6 illustrates selected aspects of the composition of an “action”cell, in particular, an icon cell, in accordance with one embodiment;

FIG. 7 enumerates selected methods associated with the variousimplementation cells to support the practice of the present invention,in accordance with one embodiment;

FIG. 8 illustrates certain novel end user interface interactionssupported under the present invention, by virtual of the architecturaldesign of the hierarchical cell based EUI, in accordance with oneembodiment;

FIG. 9 illustrates the operational flow of the relevant aspects of animplementor of the present invention, such as an application, a cellmanager or a window manager, in support of the novel end userinteractions of FIG. 8, in accordance with one embodiment;

FIG. 10 illustrates the notion of a current view, and the generation ofa next view under the present invention, in accordance with oneembodiment;

FIGS. 11-12 illustrate the operational flow of the relevant aspects ofan implementor of the present invention, such as an application, a cellmanager or a window manager, in support of automatic relative re-sizingor re-placement of region cells or zone cells, in accordance with oneembodiment;

FIGS. 13-14 further illustrate automatic relative re-sizing orre-placement of region cells and zone cells, in accordance with oneembodiment;

FIG. 15 illustrates the operational flow of the relevant aspects of animplementor of the present invention, such as an application, a cellmanager or a window manager, in support of an optimized algorithm forefficiently modifying contiguous region or zone cells, in accordancewith one embodiment;

FIG. 16 further illustrates the optimized efficient modification ofregion or zone cells of FIG. 15, in accordance with one embodiment;

FIGS. 17 a-17 b illustrate two embodiments for practicing the presentinvention;

FIG. 18 illustrate an exemplary computing system or device suitable forpracticing the present invention; and

FIG. 19 illustrates an exemplary network environment suitable forpracticing the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention includes a hierarchical cell based end userinterface, having hierarchically organized display cells (hereinafter,simply cells). The present invention also includes processes for the endusers to interact with the interface, having particular application tothe delivery of multi-media programming and/or content, as well asprocesses for automatically re-sizing and/or repositioning cells of theEUI.

In the following description, various aspects of the present inventionwill be described. However, the present invention may be practiced withonly some or all aspects of the present invention. For purposes ofexplanation, specific numbers, materials and configurations are setforth in order to provide a thorough understanding of the presentinvention. However, the present invention may be practiced without thespecific details. In other instances, well-known features are omitted orsimplified in order not to obscure the present invention.

Terminology

Parts of the description will be presented in data processing terms,such as data, variables, methods, requests, returns, and so forth,consistent with the manner commonly employed by those skilled in the artto convey the substance of their work to others skilled in the art. Aswell understood by those skilled in the art, these quantities take theform of electrical, magnetic, or optical signals capable of beingstored, transferred, combined, and otherwise manipulated throughmechanical, electrical and/or optical components of a computer system.

The term “display cell” (or “cell” for short) as used herein refers tothe logical elements or items employed to collectively implement thevarious aspects of the EUI. The logical elements/items or cells, as willbe described more fully below, are typed and include attributes definingthem, including their manifestation and behaviors. Visually, cells maybe “nested” within one another. Organizationally, cells may behierarchically related to each other.

The term “computer system” as used herein includes general purpose aswell as special purpose data processing machines, systems, and the like,that are standalone, adjunct or embedded.

Section Headings, Order of Descriptions and Embodiments

Section headings are merely employed to improve readability, and theyare not to be construed to restrict or narrow the present invention.

Various operations will be described as multiple discrete steps in turn,in a manner that is most helpful in understanding the present invention,however, the order of description should not be construed as to implythat these operations are necessarily order dependent. In particular,these operations need not be performed in the order of presentation.

The phrase “in one embodiment” is used repeatedly. The phrase generallydoes not refer to the same embodiment, however, it may.

End User View

FIG. 1 illustrates an external end user view of an exemplary end userinterface 102, implemented in accordance with one embodiment of thepresent invention. As illustrated, exemplary end user interface (EUI)102, from the end user's perspective, includes multiple display windows104 a-104 k, control facilities 106 a-106 b and icons 108 a-108 j. EUI102 may be employed to facilitate delivery of multi-media contents orprogramming for an end user. An example of such content/programmingincludes, but are not limited to, presentation of one or moreperformance or live events, such as sporting events, where the multiplewindows are employed to present different views of each performance orevent to the end user.

For ease of understanding, only a couple of control facilities 106 a-106b and a handful of icons 108 a-108 j are illustrated with windows 104a-104 k. As will be readily apparent to those skilled in the art, basedon the descriptions to follow, the present invention may be practicedwith more or less of these elements.

More importantly, as will be described in more detail below, EUI 102 isimplemented internally via a hierarchy of display cells (or cells forshort). The cells are typed and nested. Further, they have attributes,and certain attributes may be inherited in one direction, while othersin the other direction, i.e. from a higher level cell or from a lowerlevel cell. The cells are implemented as data objects with associatedmethods to facilitate manipulation of their data.

Resultantly, one of the benefits is that the views or windows 104 a-104k are readily controllable by the end user. An end user may select anyone of windows 104 a-104 k, express a desired modification or change tothe size, placement, and/or other related aspects of the windows (suchas sound). In response, the implementation logic of the presentinvention, e.g. a cell manager, or alternatively, a window manager or anapplication itself (not shown), will resize, re-position or otherwisemodify the selected windows, as well as all other impacted elements(cells) of EUI 102 accordingly and automatically.

Resizing may be expansion of a selected element or cell of EUI 102, orcontraction of a selected element or cell of EUI 102. Repositioning of acell may be within the existing immediately higher-level cell or toanother cell of EUI 102. In various embodiments, control facilities 106a-106 b are provided for the various windows 104* to facilitate a userin resizing, re-positioning or otherwise modifying the various aspectsof the windows 104*.

In one embodiment, as the selected and/or impacted windows 104* arere-sized, the content of each window 104* may be automatically scaled,preserving “full” visibility of the contents. That is, the contents ofthe various windows 104* remain in full view, scaled, but not truncatedor otherwise eclipsed. However, in alternate embodiments, one or morewindows 104* may have their contents truncated or eclipsed instead.

In one embodiment, in addition to being employed for the delivery ofmulti-media content or programming, one or more of “windows” 104 a-104 kmay be employed to present a “pool” of icons, each corresponding to anadditional displayable or launch-able cell having contents, and/oraction that may be performed on the content or the attributes of anassociated cell. The former is referred to as an “image icon”, and thecell implementing the “image icon” is an image-icon cell, whereas thelatter is referred to as a “button icon”, and the cell implementing the“button-icon” is a button-icon cell.

These and other aspects of the present invention will be described morefully below. The asterisk at the end of a reference number denotes a“wild card”, representing any of the trailing suffixes of the referencenumbers employed in a figure. For example, 104* stands for 104 a, 104 bor any one of the other 104 references of FIG. 1.

Anatomy of the End User Interface

FIGS. 2-3 illustrate the relevant aspects of the internal hierarchicalcell based implementation of EUI 102 to provide the desired improvedfeatures and behaviors, in accordance with one embodiment. Asillustrated, in accordance with the present invention, end userinterface 102 is cell based, and the constituting cells are nested (FIG.2), and the data objects implementing the cells are hierarchicallyorganized (FIG. 3).

As alluded to earlier, cells are typed, and have attributes definingtheir manifestation and behaviors. Visually, cells may be “nested”within each other. Organizationally, cells may be hierarchically relatedto each other. The attributes may be inherited in either direction, fromthe higher level cells or from the lower level cells (organizationallyspeaking).

More specifically, for the embodiment, each EUI 102 is comprised of anumber of nested “container” cells and a number “action” cells. For easeof understanding, the “outer most” (from a nesting perspective) or thehighest-level (from a hierarchy perspective) “container” cell, that isthe cell corresponding to the totality of display space available,within which all other cells are nested, is referred to as the universalor root region cell 202. Nested within universal region 202 may be oneor more nested “container” cells. In particular, at the nexthighest-level, for the embodiment, for ease of operation, the“container” cells all have visual manifestations that are rectangular inshape, and share borders. These “container” cells are referred to asregions cells 204 a-204 c.

Selected one or ones of the region “container” cells may further includeone or more nested “container” cells. For ease of understanding, thesenested “container” cells, except for ones disposed at the “inner most”nesting or “lowest” level (counting only “container” cells), arereferred to as sub-region “container” cells 205 a-205 b. The “container”cells disposed at the “inner most” nesting or “lowest” level (countingonly “container” cells) are referred to as zone “container” cells 206a-206 k. A zone “container” cell 206* dedicated to the holding of icon“action” cells (to be described more fully later), such as zone“container” cell 206 i, is also referred to as an “icon pool”.

“Action” cells, such as those implementing control facilities 208 a-208b, and icons 210 a-210 j, whether they are representing otherdisplayable or launch-able cells or merely representing actions to beperformed, i.e. image icons or button icons, may be nested within(visually speaking) or descend from (organizationally speaking)) any ofthe “container” cells, i.e. the universal region cell 202, such ascontrol facilities cells 208 a-208 b and icon cells 210 a-210 d, regionand sub-region cells 204 a-204 c and 205 a-205 b, none shown, or zone“container” cells, such as icon cells 210 e-210 j.

As described earlier, control facilities may include facilities forfacilitating minimizing or maximizing an “action” cell, and an icon“action” cell may be an image or a button icon “action” cell. The“container” cell within which another “container” or “action” cell isnested or from which the other “container” or “action” cell isdescended, is also referred to as a “host” cell.

Hereinafter, the description will be given with the relationship betweenthe various cells simply be referred to as either being “nested” inanother cell or “descended” from another cell, depending on whichcharacterization is more meaningful in view of the context. However, thereference expressed from one perspective (visual or organizational) isan expression in both perspectives, even expression in the otherperspective is not explicitly stated.

Continuing now with the description and referring in particular to FIG.3, for the embodiment, the data, such as attribute data (described morefully below), associated with each cell, 202 and 204*-210*, whether“container” or “action”, are organized and implemented as an hierarchyof data objects 302 and 304*-306*, with data object 302 corresponding touniversal region cell 202 being the root object of the hierarchy, dataobjects 304* corresponding to region cells 204* being descendant dataobjects of root object 302, data objects 305* corresponding tosub-region cells 205* being descendant data objects of the data objects304*-305* of their “host” region/sub-region cells 204*/205*, and dataobjects 306* corresponding to zones cells 206* being descendant dataobjects of the data objects 302 and 304*-305* of their hostuniversal/region/sub-region cells 202 and 204-205.

Contents to be presented in various windows 104*, such as video 308a-308 e, graphics 310 a-310 b and texts 312 a-312 c are effectuated byassociating the data objects of these contents with data objects 306* ofthe zone “container” cells 206* corresponding to windows 104*. Dataobjects 314 a-314 h and 316 a-316 b implementing icons 210 a-210 j andcontrol facilities 208 a-208 b are descendant data objects of the dataobjects of their respective host universal/regions/sub-regions/zones 202and 204*-206*.

Resultantly, the novel architecture and data organization enablecontents provided through different display windows 104* to be easilyswappable, by swapping the association of the contents' data objectswith the “host” zone cell 206*. Similarly, the associations of “action”cells 208* and 210* with the different cells 202 and 204*-206* may alsobe easily changed, by changing the association between data objects314*-316* with data objects 302 and 304*-306* of cells 202 and204*-206*.

For ease of understanding, only one zone “container” cell 206 a andlimited number of “action” cells 208 a and 210 a-210 b are illustratedas being directly nested in universal region 202, only one region“container” cell 304 b as having sub-region-“container” cells 254*, andonly one zone “container” cell 206 i is deployed as an icon pool in FIG.2-3. However, the present invention contemplates multiple nesting ofmultiple “container” and “action” cells, e.g. more region/zone“container” cells as well as “action” cells may be nested in universalregion 202, more third level sub-region “container” cells and/or“action” cells may be nested within region “container” cells of thesecond level. From the description thus far and the ones to follow,those skilled in the art will be able to practice the present inventionin such multi-level manner, should that be desired.

Anatomy of “Container” Cells

FIGS. 4-5 illustrate the composition of “container” cells, inparticular, a region “container” cell and a zone “container” cell, inaccordance with one embodiment. From the processing or computationperspective, the earlier described universal region cell 202, region“container” cell 204*, and sub-region “container” cells 205* are merelydifferent variants the region “container” cell to be described.Accordingly, the composition descriptions to follow apply equally touniversal region-cell 202, region “container” cell 204*, and sub-region“container” cells 205*.

As illustrated, for the embodiment, associated with the definition ofeach region/zone “container” cell 202 and 204*-206*, and stored insidecorresponding data objects 302 and 304*-306* are attributes definingwhether a “container” cell 204*-206* is dynamic or fixed (i.e. createdon an as needed basis, or always present), whether the “container”cell's position is movable or stationery, its relative priority to other“container” cells 204*-206*, a center position, a base, a height and amaximum size of the region/zone “container” cells 204*-206*:

region “container” cell zone “container” cell region_type = [dynamic,fixed] zone_type = [dynamic, fixed] region_position = [stationary,zone_position = [stationary, movable] movable] region_priority = [1, 2,3 . . . ] zone_priority = [1, 2, 3 . . . ] region_center_positionzone_center_position region_base zone_base region_height zone_heightregion_maximum_size zone_maximum_size

Additionally, for the embodiment, associated with the definition of eachregion/zone “container” cell 202 and 204*-206*, and stored insidecorresponding data objects 302 and 304*-306* are attributes defining akernel 402/502 of the region/zone “container” cell 204*-206*. A kernelof a region/zone “container” cell 204*-206* refers to the smallestmanifestation of the region/zone “container” cell 204*-206*. That is,when the available space within a host “container” cell 202-205* fallsbelow the space required by the kernel of a region/zone “container” cell204*-206*, the “container” cell 204*-206* is to be “reduced” to an iconcell. For the embodiment, the kernel related attributes includeattributes defining a region/zone “container” cell's kernel's size, baseand height.

region-cell zone-cell region_kernel_area zone_kernel_arearegion_kernel_base zone_kernel_base region_kernel_heightzone_kernel_height

Further, for the embodiment, associated with the definition of eachregion/zone “container” cell 202 and 204*-206*, and stored insidecorresponding data objects 302 and 304*-306* are attributes defining aboundary 406/506 of the region/zone “container” cell 204*-206*. Theboundary related attributes include attributes defining a thickness anda color of the boundary of the region/zone “container” cell 204*-206*.

region-cell zone-cell region_boundary_thickness zone_boundary_thicknessregion_boundary_color zone_boundary_color

In one embodiment, if the “boundary” attributes are not specified for aregion/zone “container” cell, the region/zone “container” cellautomatically inherits the “boundary” attributes of the nearest“ancestor” region “container” cells, where such attributes arespecified. In other words, an inheriting region/zone “container” celltakes on the characteristics of the bequeathing “ancestor” region“container” cell.

Associated with the definition of each region/zone “container” cell 202and 204*-206*, and stored inside corresponding data objects 302 and304*-306* are also attributes defining a border 404/504 of theregion/zone “container” cell 204*-206*. The border related attributesinclude attributes defining a thickness, a color, a texture, a shading,a blinking and a transparency attribute of the border of the region/zone“container” cell 204*-206*.

region-cell zone-cell region_border_thickness zone_border_thicknessregion_border_color zone_border_color region_border_texturezone_border_texture region_border_shading zone_border_shadingregion_border_blinking zone_border_blinking region_border_transparentzone_border_transparent

In one embodiment, if the “border” attributes are not specified for aregion/zone “container” cell, the region/zone “container” cell alsoautomatically inherits the “border” attributes of the nearest “ancestor”region “container” cell, where such attributes are specified.

In various embodiments, for a region “container” cell 204*-205*, theattributes may further include attributes defining how many zone“container” cells it may have, their names and their default alignments(e.g. center, top, bottom, right, left and so forth), whereas for a zone“container” cell 206*, the attributes may further include an attributedefining its “host” region “container” cell 202 and 204*/205*. For azone “container” cell 206*, the attributes may further includeattributes defining its content types, video, data, image, text, and soforth, and an external buffer 508. External buffer 508 defines theminimum inter-zone “container” cell spacing between immediately adjacentzone “container” cells 206*.

region-cell zone-cell region_zone_list = [zone-cellzone_region_association ames] region_zone_alignment = [center,zone_video, zone_data, top, bottom, right, left] zone_image, zone_textregion_max_allowable_zones = [number]

The above described attributes for region/zone “container” cells aremerely illustrative. In alternate embodiments, the present invention maybe practiced with more or less region/zone “container” cell attributes.For example, the present invention may be practiced with additionalattributes defining

a) the control facilities associated with the region/zone “container”attributes,

b) the behavior when certain areas of a region/zone “container” cell is“mouse over”, and

c) forced bequeathing of certain attributes to the more inner or lowerlevel region/zone “container” cells.

Anatomy of an “Action” Cell

FIG. 6 illustrates the composition of an “action” cell, morespecifically, an image icon “action” cell in further detail, inaccordance with one embodiment. As described earlier, an image icon“action” cell is an iconic representation of another displayable orlaunch-able cell with content, control facilities and so forth. Further,“action” cells may also include cells defining control facilities, andcells defining “button” icon, which provide control facilities for aregion/zone “container” cell and action to be performed within aregion/zone “container” cell respectively. The description to follow foran image icon “action” cell may be likewise adopted to implement buttonicon “action” cells and/or control facilities cells.

As illustrated, for the embodiment, associated with the definition ofeach image icon “action” cell 208*-210* and stored inside acorresponding data object 314*-316* are attributes defining the bit mapof the image icon “action” cell, the center position of the image icon“action” cell, a region/zone “container” cell with which the image icon“action” cell is associated, and a buffer 602. Buffer 602 defines theminimum space required to display the image icon “action” cell.

Icon-cell image_icon_association = [region/zone-cell name]image_icon_center_position = [x, y] image_icon_actual = [bit_map_name]image_icon_buffer_base = [ ] image_icon_buffer_height = [ ]image_icon_upper_left_vertex_position = [x, y]

Similarly, in alternate embodiments, the present invention may bepracticed with more or less attributes defining the various “action”cells, as well as the contents to be rendered (i.e. video, graphics,texts, and so forth). In particular, for button icon “action” cells andcontrol facility “action” cells, each of the respective “action” cellsmay include one or more attributes in identifying the binaries to beexecuted responsive to various types of user actions, e.g. “mouse over,”“single click,” “double clicks,” and so forth.

Implementation Methods of “Container” and “Action” Cells

Referring briefly to FIG. 3 again, as described earlier, for theillustrated embodiment, region/zone “container” cells, “action” cells,and data (include video, graphics, text and so forth) are implemented inan object oriented manner, with corresponding data objects 302 and304*-316*. In one embodiment, as illustrated in FIG. 7, various methods700 are associated with the data objects 302 and 304*-316*. For theembodiment, these methods include in particular a clear, a contract, anexpand, a remove, and a set attribute method, 702-710, associated withthe root data object 302, and inherited by the descendant data objects304*-316* of the nested region/zone “container” cells 204*-206*, as wellas the descendant data objects 314*-318* of the nested “action” cells208*-210*.

Clear method 702, when invoked against universal region “container”cell's data object 302 clears the EUI 102, i.e. removing all nestedregion/zone “container” cells 204*-206*, including their contents, aswell as any nested “action” cells 208*-210*. In one embodiment, theuniversal region “container” cell clearing is efficiently achieved byclearing or deleting all descendant data objects 304*-316*. Innerinvocation against a region/zone “container” cell 204*-206* clears thenested regions/zones “container” cells 204*/206* within the targetregion/zone “container” cell 204* including their contents, and anynested “action” cells 208*-210*. In like manner, the clearing isefficiently achieved by clearing or deleting the applicable descendantdata objects 304*-316*.

Expand and contract methods 704-706 are employed to expand and contracta region/zone “container” cell 204*-206* respectively. Remove method 708facilitates removal of individual cells of the EUI 102, i.e. one or moreregions/zone “container” cells 204*-206* or “action” cells 208*-210*without clearing all cells. Removal is achieved in like manner as clearmethod 702, except the operation is applied to selected ones of thedescendant data objects, as opposed to all descendant data objects. SetAttribute method 710 facilitates setting of the earlier describedregion/zone “container” cell and “action” cell attributes associatedwith region/zone “container” cells 202 and 204*-206*, and “action” cellsrespectively.

For region/zone cells 204*-206* and “action” cells 208*-210*, theircorresponding data objects 304*-306* and 314*-316* further include theassociation of a create, and a delete, a move and a place method712-718. Create and delete methods 712-714, as their names suggest,facilitate creation and delete of the various descendant data objects304*-306* and 314*-316* for the nested region/zone “container” cells and“action” cells 204*-206* and 208*-210*. Move and place methods 716-718,as their names suggest, facilitate movement and relocation of thevarious region/zone “container” cells and “action” cells 204*-206* bymodifying e.g. the position attributes of the corresponding data objects304*-306* and 314*-316*.

For the embodiment, data objects 314*-316* for “action” cells 208*-210*further include the association of a launch method 720 for launching adisplayable region/zone cell 204*-206* represented by image icon“action” cells 210*.

With the exception of the handling of the impact that flows from thecreation, deletion, expansion and contraction of a region/zone“container” cell 204*-206*, implementation of the above describedmethods are within the ability of those ordinarily skilled in the art,accordingly will not be further described. Handling of the impact thatflows from the creation, deletion, expansion and contraction of aregion/zone “container” cell 204*-206* will be described in more detailbelow, referencing FIGS. 11-16.

Interacting with EUI

FIGS. 8-9 illustrate two novel interactions with EUI 102, otherwise notavailable under the prior art, and the relevant operation flow of animplementor, such as an application, a cell manager or a window manager,incorporated with the teachings of the present invention. Asillustrated, by virtue of the earlier described novel architecture anddata organization, contents presented through two different zone“container” cells 206* may be easily interchanged or swapped, as denotedby arrow 802. The swapping operation may be initiated through any one ofa number of user key sequences, e.g. user key sequences similar to aconventional drag and drop operation. The swapping may be efficientlyaccomplished by switching association of the applicable data objects308*-316* and their region/zone “container” cells 204*-206*. Further,“action” cells 314*-316* may be easily relocated to any region/zone“container” cell 204*-206* as denoted by arrow 804.

As illustrated in FIG. 9, in response to a non-region/zone “container”cell impacted user interaction, an implementor (such as an application,a cell manager or a window manager incorporated with the teachings ofthe present invention) determines if the sequence of user inputs denotesa drag and drop of content from one region/zone “container” cell204*-206* to another, block 902. If so, the implementor effectuates thecontent swapping, by switching the data objects' association with theirregion/zone “container” cells 204*-206*, as earlier described, block904.

If the sequence of user inputs does not denote a drag and drop ofcontent, for the embodiment, the implementor further determines if thesequence of user inputs denotes an “action” cell drag and drop, block906. If so, the implementor effectuates the “action” cell movement andplacement by similarly switching the “action” cell's association withregion/zone “container” cells 204*-206*, optionally launching therepresented region/zone “container” cell 204*-206* and its contents (ifso requested by the sequence of user inputs), block 908.

If the sequence of user inputs does not denote either one of these novelinteractions supported, the denoted prior art request may then beprocessed as in the prior art.

The sequence of user inputs denoting the earlier described content and“action” cell drag and drop may be practiced through any key sequences,e.g. by clicking on the content or icon, using a cursor control device,and keeping the applicable click button of the cursor control deviceheld down, until the target region/zone “container” cell 206* isreached. At such time, the click button of the cursor control device maybe returned to its normal position. In alternate embodiments, thepresent invention may be practiced with other key sequences instead.

Transition from a Current View to a Next View

FIG. 10 illustrates an overview of the operation of EUI 102. The currentstate of EUI 102 as defined by the current states of the correspondingdata objects 302-316* of the constituting cells 202-210* of EUI 102, asillustrated, is referred to as the current view of EUI 102. In responseto user interactions, such as a request to add or remove a region/zone“container” cell 204*-206*, or a request to expand or contract aregion/zone “container” cell 204*-206*, the implementor of the presentinvention, e.g. an application, a cell manager or a window manager,performs a series of responsive calculations, and generate the next viewof EUI 102.

The operational flow of the relevant aspects of the implementor, inresponse to the various user interactions of interest, will be describedin turn below.

Addition/Expansion of a Region/Zone “Container” Cell

FIG. 11 illustrates the operational flow of the relevant aspects of animplementor, e.g. an application, a cell manager or a window manager,for responding to a request to add a region/zone “container” cell or an“action” cell to a region/zone “container” cell, or expand a region/zone“container” cell (hereinafter, for the description of FIG. 11, simplythe “add/expand” request), in accordance with one embodiment. Asillustrated, for the embodiment, the implementor first determines if therequested addition or expansion fits in the current available space ofthe host region/zone “container” cell, block 1102. The required space toaccommodate the requested addition/expansion may e.g. be determined fromthe attribute values of the “new” or expanded region/zone “container”cell. If the requested addition or expansion fits in the currentavailable space of the host region “container” cell, the requestedaddition or expansion is performed accordingly, block 1104.

However, if the requested addition or expansion does not fit in thecurrent available space of the host region/zone “container” cell, theimplementor successively undertakes one or more space creation actions,until either sufficient amount of available space has been created oruntil all possible space creation actions have been exhausted, blocks1102-1108. As soon as sufficient available space has been created,operation continues at block 1104 as earlier described.

However, if all possible space creation actions have been exhausted andthe amount of space required to accommodate the requested addition orexpansion remains insufficient, the implementor successively undertakesone or more space requirement reduction actions, until either therequired space has been reduced below the amount of available space oruntil all possible space reduction actions have been exhausted, blocks1110-1112. Similarly, as soon as the required space to satisfy theaddition or expansion request is reduced below the available space,operation continues at block 1104 as earlier described.

If likewise, all possible required space reduction actions areexhausted, and the amount of space required to accommodate theadd/expand request remains above the available space, an “error”, suchas “unable to add/expand”, is returned in response to the request.

In one embodiment, available space creation actions include shiftingexisting region/zone “container” cells within the host region/zone“container” cell the add/expand request is to be performed, and reducingthe existing region/zone “container” cells if necessary. In oneembodiment, shifting of existing region/zone “container” cells includesshifting the existing regions/zone “container” cells to a predeterminedcorner of the host region/zone “container” cell, e.g. the lower leftcorner, the upper left corner, the upper right corner or the lower rightcorner. In one embodiment, shifting of existing region/zone “container”cell to a corner is performed by aligning the region/zone “container”cells along one or the other boundary forming the corner. In anotherembodiment, shifting of existing region/zone “container” cells to acorner is performed by alternating in aligning the regions/zone“container” cells along the boundaries forming the corner.

In one embodiment, reducing the existing region/zone “container” cellsis performed in an incremental manner. In another embodiment, reducingthe existing region/zone “container” cells is performed in accordancewith the relative priorities of the existing region/zone “container”cells. In one embodiment, reduction is performed in an incrementalmanner as well as in view of the relative priorities of the existingregion/zone “container” cells. In one embodiment, the lowest priorityregion/zone “container” cell is first successively reduced to its kernelbefore the next higher priority region/zone “container” cell issuccessively reduced towards its kernel. In another embodiment, thereduction is successively performed in a round robin manner. In yetanother embodiment, reduction of existing region or zone “container”cells further includes reducing one or more of the existing region/zone“container” cells to their icon “action” cell representations. Again, inone embodiment, the reduction to iconic representation is performed inview of the relative priorities of the existing region/zone “container”cells.

In one embodiment, reduction of required space action includessuccessively reducing the size of the region/zone “container” cell to beadded, or to be expanded to.

Still referring to FIG. 11, back at block 1104, upon performing therequested addition/expansion, the implementor determines if any postaddition/expansion operations need to be performed. If so, the postaddition/expansion operations are performed, block 1118. If not, theprocess terminates.

Post addition/expansion operations may be required, as existingregion/zone “container” cells may have been shifted to one corner of thehost region/zone “container” cell or reduced, even to their kernel, inthe course of accommodating the addition/expansion request. Accordingly,for the embodiment, upon accommodating the addition/expansion, attemptsare made to at least partially restore the shifted and/or reducedregion/zone “container” cells back to the pre-request state. Similarly,the post addition/expansion operations may include successivelyexpanding reduced existing region/zone “container” cells, which may alsobe performed in view of the relative priorities, re-shifting shiftedregion/zone “container” cells (e.g. out from the coalesce corner) toachieve a more balance alignment of the nested region/zone “container”cells within the host region “container” cell. “Balance” may be measurede.g. by the average space gap between the boundaries of the variousregion/zone “container” cells.

FIG. 13 illustrates an exemplary addition of a new region/zone“container” cell into a region “container” cell having two existingregion/zone “container” cells, in accordance with the above describedprocess. As illustrated, the two existing region/zone “container” cellsare first shifted to the lower left corner, with the two existingregion/zone “container” cells aligned along the left boundary formingthe lower left corner (illustrations A & B). Since there isn't enoughavailable space to add the requested new region/zone “container” cell,the two existing region/zone “container” cells are successively reduced,eventually to their kernels, first the lower priority region/zone“container” cell, then the higher priority region/zone “container” cell(illustrations C-D). The new region/zone “container” cell is then addedto the newly created space in the opposite upper right corner(Illustration E). Further, the reduced region/zone “container” cells areshifted back out from the lower right corner and aligned in the bottomportion of the host region/zone “container” cell (illustration F & G).

FIG. 14 illustrates another exemplary addition of a new region/zone“container” cell into a region/zone “container” cell having threeexisting region/zone “container” cells, in accordance with the abovedescribed process. Except in this illustration, the existing region/zone“container” cells are first shifted to the upper left corner, and thenshifted out along the top portion of the host region/zone “container”cell instead. Further, the new region/zone “container” cell is reducedto reduce its space requirement before it is added to the hostregion/zone “container” cell.

Removal/Contraction of a Region/Zone “Container” Cell

FIG. 12 illustrates the operational flow of the relevant aspects of animplementor, e.g. an application, a cell-cell manager or a windowmanager, for responding to a request to remove a region/zone “container”cell from a region “container” cell, or an “action” cell from aregion/zone “container” cell (hereinafter, for the description of FIG.12, simply the “remove/contract” request), in accordance with oneembodiment. As illustrated, for the embodiment, the implementor removesor contracts the region/zone “container” cell, or the “action“cell asrequested, block 1202. Thereafter, the implementor determines if thethere are iconized region/zone “container” cells of the host region/zone“container” cell that can be restored into the newly increased availablespace of the host region/zone “container” cell, block 1204. If so, theimplementor restores one or more of the eligible iconized region/zone“container” cells, subject to the available space, block 1206. In oneembodiment, the restoration is performed in accordance with the relativepriorities of the iconized region/zone “container” cells.

Upon exhausting the possibility of restoring iconized region/zone“container” cells (either because there are none left or there isn'tenough space), the implementor determines if there are any reducedregion/zone “container” cells that can be grown towards their maximumsizes, block 1208. If so, the implementor successively grows one or moreof the reduced region/zone “container” cells, subject to the availablespace, block 1210. In one embodiment, the successive growth is alsoperformed in accordance with the relative priorities of the reducedregion/zone “container” cells.

Next, similar to the process of adding or expanding a region/zone“container” cell, upon restoring or growing the iconized or reducedregion/zone “container” cells, the implementor determines if any postrestoration or growth actions need to be performed, block 1212. If so,the implementor performs the post restoration or growth actions, such asshifting and aligning to “re-balance” the region/zone “container” cellsof the host region/zone “container” cell, block 1214. As before,“balance” may be measured e.g. by the average space gap between theboundaries of the various region/zone “container” cells

Alternate Embodiment—Extended Boundary Method

FIG. 15 illustrates the operational flow of the relevant aspects of animplementor, e.g. an application, a cell manager or a window manager forresponding to a request to expand a region “container” cell(hereinafter, for the description of FIG. 15, simply the “add/expand”request), in accordance with another embodiment. In this embodiment, forefficiency of operation, region “container” cells are nested within ahost region “container” cell in a contiguous manner, i.e. withoutavailable space gap between their boundaries.

As illustrated, in response to a request to grow a region “container”cell by an amount, the implementor first generates extended boundariesfor the growth region “container” cell (see FIG. 16), block 1502. Next,the implementor determines growth impact for up to n levels removed inall directions, using the extended boundaries.

For example, for the exemplary growth request illustrated in FIG. 16,growth impact of the center region “container” cell may be determinedusing its extended boundaries, based on their intersections with otherboundaries. The impacts on region “container” cells up to 2 degreesremoved from the center region “container” cell may be summarized asfollows:

up down left right Neighbor region A, B 1) F, E H, G C, D “container”cell affected Second level none none special case L, K, J region“container” cell affected Side Effects H, C D F none

Thereafter, for the embodiment, the implementor iteratively expands theregion “container” cell in the various directions, adjusting theimpacted region “container” cell to accommodate the growth, block 1506.The process continues until the desired amount of growth is achieved. Ifthe desired growth is not achievable, for the embodiment, an “error”,such as “growth unachievable”, is returned, block 1508.

Implementor

As alluded to earlier, the present invention may be practiced e.g. byendowing an application itself, a cell manager or a window manager withthe teachings of the present invention. In the latter cases, acell/window manager implementor may be effectuated in at least twomanners, FIG. 17 a and FIG. 17 b. In the embodiment of FIG. 17 a, cellmanager 1704 is equipped with teachings of the present inventioninterfaces and interacts with applications 1702 using its services, anddisplay device driver 1706 as in the prior art. Accordingly, under thisembodiment, typically, the universal region “container” cell 202 is theentire display space of a display device.

In the alternate embodiment of FIG. 17 b, the cell manager implementoroperates as an “auxiliary” cell manager 1703 to a conventional windowmanager 1704. Applications 1702 may interact with conventional windowmanager 1704 directly or indirectly through auxiliary cell manager 1703(equipped with the teachings of the present invention). Accordingly,universal region “container” cell 202 may be a window of a conventionalwindow approach, except within that window, the EUI is implemented andpracticed as earlier described, in accordance with the presentinvention.

In yet other alternate embodiments, auxiliary cell manager 1703 may beintegrally incorporated as part of window manager 1704.

Example Computer System

FIG. 18 illustrates an exemplary computer system or device suitable forpracticing the present invention, in accordance with one embodiment. Asshown, computer system/device 1800 (hereinafter simply “device”)includes one or more processors 1802 and system memory 1804.Additionally, device 1800 includes mass storage devices 1806 (such asdiskette, hard drive, CDROM and so forth), input/output devices 1808(such as keyboard, cursor control and so forth) and communicationinterfaces 1810 (such as network interface cards, modems and so forth).The elements are coupled to each other via system bus 1812, whichrepresents one or more buses. In the case of multiple buses, they arebridged by one or more bus bridges (not shown). Each of these elementsperforms its conventional functions known in the art. In particular,system memory 1804 and mass storage 1806 are employed to store a workingcopy and a permanent copy of the programming instructions implementingthe implementor of the present invention, e.g. an application, a cellmanager or a window manager. The permanent copy of the programminginstructions may be loaded into mass storage 1806 in the factory, or inthe field, through a distribution medium (not shown) or throughcommunication interface 1810 (from a distribution server (not shown)).The constitution of these elements 1802-1812 are known, and accordinglywill not be further described.

Example Network Environment

FIG. 19 shows an exemplary network environment suitable for practicingthe present invention, in accordance with one embodiment. In thisembodiment, contents are presented for user of client device 1902 toenjoy, employing the hierarchical cell based EUI 102 of the presentinvention. In one embodiment, display device 1904 a on which EUI 102 isrendered, is an integral of client device 1902. In another embodiment,display device 1904 b on which EUI 102 is rendered, is an separate anddistinct “peripheral” of client device 1902.

In various embodiments, the implementor of the present invention, e.g.an application, a cell manager or a window manager, may be executing onclient device 1902 itself. In other embodiments, the implementor may beexecuting on server 1906 instead. Examples of the former case may be apersonal computer, an enhanced integrated television set, and a set-topbox. Examples of the latter case may be a content streaming server or acable programming broadcasting device.

Client device 1902 and server 1906 are coupled to each other via one ormore private and/or public networks, including e.g. the Internet,employing Digital Subscriber Lines (DSL) (or other variants xDSL), CableNetwork, Integrated Digital Service Network (ISDN), AsynchronousTransfer Mode (ATM), Frame Relay, or other high performancecommunication links/connections of like kind. Communications betweenclient device 1902 and server 1906 may be accomplished via any one of anumber of communication protocols known in the art, including but arenot limited to the TCP/IP protocol.

Examples of content may include one or more of the following content orprogram types

Special Events a) News b) TV c) Sports Concerts Live Reality GolfProduced Olympics Shows Network Football Political Rallies SyndicationRacing Amusement Children's TV Football Plays Treasure Hunts Soccer

Conclusion & Epilog

Thus, a novel EUI method and apparatus has been described. While thepresent invention has been described with the foregoing embodiments, thepresent invention is not so limited. The present invention may bepracticed with modifications and extensions to the earlier describedembodiments. The full scope of the present invention is defined by theclaims to follow.

1-14. (canceled)
 15. In a computing environment having a processor, amemory, and a display device, a method of operation comprising:rendering on the display device, by an application or a display driveroperated by the processor, a plurality of display windows in anon-overlapping manner, unaligned horizontally and vertically, usingcomputationally an hierarchy of display container cells created andstored in the memory, wherein the hierarchy of display container cellscomprises at least two levels of display container cells; and receivingby the application or display driver, a request to expand, contract orremove a selected one of the display windows; expanding, contracting orremoving the selected one of the display window, by modifying one ormore of the display container cells, including modifying the one or moredisplay container cells to achieve at least one of shifting orrepositioning one or more of the other display windows to coalesceavailable space between the display windows, or downsizing or upsizingone or more of the other display windows to increase or decreaseavailable space between the display windows.
 16. The method of claim 15,wherein modifying one or more of the display container cells comprisesmodifying the one or more of the display container cells to the displaywindows to a corner of an area of the display device.
 17. The method ofclaim 15, wherein modifying one or more of the display container cellscomprises successively modifying the one or more of the displaycontainer cells to successively downsize the display windows.
 18. Themethod of claim 17, wherein successively modifying the one or more ofthe display container cells to successively downsize the display windowscomprises successively modifying the display container cells in order oftheir relative priorities.
 19. The method of claim 15, whereinsuccessively modifying the one or more of the display container cells tosuccessively downsize the display windows comprises modifying one ormore display containers to transform one or more of the display windowsto their kernel forms.
 20. The method of claim 15, wherein successivelymodifying the one or more of the display container cells to successivelydownsize the display windows comprises modifying one or more displaycontainers to transform the one or more display windows to one or moreimage icons.
 21. The method of claim 15, wherein the method furthercomprises upon modifying the display container cells to accommodate arequest to accommodate a request to expand a selected one of the displaywindows, re-modifying one or more of the display container cells toachieve at least one of upsizing one or more downsized display windows,and back-shifting one or more shifted display windows.
 22. The method ofclaim 21, wherein re-modifying one or more of the display containercells to achieve upsizing of one or more downsized display windowscomprises successively re-modifying the one or more of the displaycontainer cells to upsize the downsized display windows.
 23. The methodof claim 21, where re-modifying one or more of the display containercells to back-shift one or more shifted display windows comprisesre-modifying one or more of the display container cells to successivelyback-shift the shifted display windows.
 24. The method of claim 15,further comprising upon modifying one or more display container cells todownsize one or more display windows, down scaling one or more contentof one or more downsized display windows to enable the one more contentsto remain fully visible within the downsized windows.
 25. The method ofclaim 15, further comprising upon modifying one or more displaycontainer cells to upsize one or more display windows, upscaling one ormore content of one or more upsized display windows to enable the onemore contents to fully utilize all space within the upsized windows. 26.The method of claim 15, wherein rendering comprises the application ordisplay driver using an hierarchy of display container cells including ahost display container cell created and stored in the memory, andwherein the method further comprises the application or display drivercoupling at last some of the plurality of display container cells to thehost display container cell as children display container cells of thehost display container cells, with each of the display container celllogically inheriting at least an attribute or a method of the hostdisplay container cell.
 27. The method of claim 15, wherein renderingcomprises the application or display driver using an hierarchy ofdisplay container cells including a number of display container cellsgreater than a number of the plurality display windows, and wherein themethod further comprises the application or display driver coupling atleast a first of the display container cell as a child display containercell of a second display container cell, with the first displaycontainer cell logically inheriting at least an attribute or a method ofthe second display container cell.
 28. The method of claim 27, whereincoupling at least a first of the display container cell as a childdisplay container cell of a second display container cell, comprises theapplication or display driver coupling at least a first of the displaycontainer cell with associated content as a child display container cellof a second display container cell without associated content.
 29. Themethod of claim 15, wherein rendering comprises the application ordisplay driver using an hierarchy of display container cells including anumber of display container cells that are typed, with each of at leasesome display container cells having one or more attributes, including apriority attribute, and wherein the application or display drivermodifying the one or more display containers based at least in part onthe priority attribute(s) of the one or more display containers.
 30. Amethod for operating a computing device, the method comprising:rendering on a display device of the computing device, by an applicationor a display driver operated by a processor of the computing device, anend user interface having a plurality of windows with correspondingcontents, using computationally a plurality of display container cellscreated and stored in a memory of the computing device, wherein eachdisplay container cell has one or more associated attributes, includinga priority attribute; receiving by the application or display driver arequest to expand, contract or remove one of the display windows;expanding, contracting or removing the one display window, by theapplication or display driver, including at least one of expanding,contracting, shifting or repositioning one or more of other ones of theplurality of display windows, by modifying one or more of the displaycontainer cells, including modifying one or more of the displaycontainer cells based at least in part on the priority attributes of theone or more display container cells.
 31. The method of claim 30, whereinrendering comprises rendering by the application or device driver theplurality of windows in a non-overlapping configuration, unalignedhorizontally and unaligned vertically.
 32. The method of claim 30further comprising: receiving by the application or display driver arequest to add to the end user interface another display window havinganother corresponding content, wherein the second display window isimplemented computationally using another display container cell; andadding to the end user interface the another display window, by theapplication or display driver, including at least one of expanding,contracting, shifting or repositioning one or more of the plurality ofdisplay windows, by modifying one or more of the corresponding displaycontainer cells of the one or more of the plurality of display windows,based at least in part on the priority attributes of the one or morecorresponding display container cells.
 33. The method of claim 30,further comprising upon modifying one or more display container cells todownsize one or more display windows, down scaling one or more contentof one or more downsized display windows to enable the one more contentsto remain fully visible within the downsized windows.
 34. The method ofclaim 30, further comprising upon modifying one or more displaycontainer cells to upsize one or more display windows, upscaling one ormore content of one or more upsized display windows to enable the onemore contents to fully utilize all space within the upsized windows.